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DETAILED ACTION 



1. This communication is in response to Appeal Brief, filed 11/13/01, claims 1-28 remain 
pending. 

2. Applicant's request for reconsideration of the finality of the rejection of the last Office 
action is persuasive and, therefore, the finality of that action is withdrawn. 

3. Quotation of 35 U.S.C. §103(a) which forms the basis for all obviousness rejections set 
forth in this Office action may be found in previous office action; 

4. Claims 1-18 are rejected under 35 U.S.C. 103(a) as being unpatentable over Heil et. al. 
(Heil) U.S. Patent No. 6,173,374 in view of Intelligent I/O (120) Architecture Specification 
(Specs), version 1.5, March 1997. 

Regarding claims 1, and 14. Heil teaches a host driver configuration of a host driver module of a 
computer node on a server cluster, comprising: 

an input/output platform (lOP) arranged to control an array of local storage devices; 

Heil teaches a host driver configuration of a host driver module (col 10/line 28-50) 
of a computer node on a server cluster, (Heil, abstract), teaching HBA(s) embedded intelligent I2O 
standard software, partitions the device driver into one module creating stackable drivers 210-280, 
col 10/lines 28-31, and col 10/lines 43-col 11/line 4; Software drivers 240, 250, and 260 are 
arranged to control an array of local storage devices. Fig. 2, wherein 1/0 redirector driver software 
240 determines whether to satisfy a block l!Q request locally or remotely, and coordinates the 
retrieval of data over a cluster with logically shared disks, clusters drives, comprising local stored 
data blocks, col 11/lines 5-11; fixrther using software drivers ISM 250/HDM 260 to control local 
disks 118, col 11/lines 12-27. 

a system driver module comprising: a Local Transport arranged to provide an interface to 
said input/output platform (lOP); 

Heil teaches software driver 250 arranges to provides an interface layer to 
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said host (I2O standard software) driver module structure, Fig. 1\ driver (ISM) 250 is arranged to 
control local disks 118, to retrieve and request block level I/O requests from the local disks 118 and 
post blocks of data to the local disks 118, 123, col 1 1/lines 7-12, 28-35, 

a Remote Transport arranged to provide an interface to export local storage device access 
onto a computer network; a host driver module architecture on a server cluster for providing I/O 
access storage device data transfer between computer node(s) on a server cluster system and 
another system; 

Heil teaches software drivers 240 is arranged to provide an interface layer to 
a computer network; Fig. 2; provides managing means to allow the host driver module (HBA) to 
determine whether to satisfy a block i/O request locally or remotely, managing means coordinates 
the retrieval of data over a cluster with logically shared disks, cluster drives, comprising local or 
remote stored data blocks, col 1 1/lines 5-11; wherein software drivers I/O shipping 270 and HDM 
280 provide an interface layer for exporting local storage device onto a computer network, I/O 
shipping 270 managing the reception of remotely generated requests from the other system network 
for local data to be exported onto the computer network, and I/O shipping HDM 280 manages the 
communication medium (FC) transactions in support of shipping functions, col 1 1/lines 36-46. 

a Connection Manager arranged to estabhsh connection services with remote servers on said 
computer network and coordinate functions responsible for creating a direct call path between the 
software driver 250 and software driver 240 to provide access to the local storage devices. 

Heil teaches establishes a communication over an FC backbone network between 
the initial host system on a computer node and the remote HBA host system on a computer node 
attached to the storage location owning the requested I/O blocks, and ships the block L'O request to 
the peer HBA's remote disk, col 1 1/lines 45-65, and col 4/lines 58-61, data is transferred across 
computer nodes of a server cluster system by providing for I/O shipping of data blocks to peer host 
system, see abstract; 

however Heil does not teach functions responsible for creating a direct call path between the 
transport driver modules to provide access to the local storage devices; nor wherein that embedded 
intelligent I2O standard software comprises an lOP platform; 

Specs teaches a message-based interfaces enable direct messages passing between 
any two device driver module for a particular class of I/O messages class, section 1.1.2.2, page 1-4, 
utility message (call) functions, table page 6-4 comprising message codes for accessing devices. 
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Upon initialization the host then gives each lOP a list of all lOPs and the physical location of their 
inbound message queue. When an lOP wants to connect to another lOP, it sends the request to the 
respective lOP's inbound message queue location. The connection request and its reply convey 
information enabling the two lOPs to establish a direct path for exchanging messages, section 
2.1.4.1, and page 2-11. 

In accordance with I2O standard architecture, this protocol comprises a single host entity 
and an intelligent I/O subsystem containing a number of I/O processors entities, host comprising 
application(s) and their resources, executing an operating system, Fig. 2-1, an lOP platform 
consists of a processor, memory and I/O devices, as per architecture's standard on page 2-1. 

Therefore Heil teachings wherein an HBA executing embedded intelligent software is 
arranged to control an array of local storage devices, inherently teach that an input/output platform 
(lOP) arranged to control an array of local storage devices. 

It would have been obvious to one ordinary skilled in the art at the time the invention was 
made to enable means for creating a direct call path between the driver modules to provide access 
to the local storage device, as taught by Specs, motivation would be enable a direct message 
passing between software driver layer for a particular class of I/O, such as those fiirther specified 
by I2O standards such as LAN ports, Ethernet or Token ring controllers, SCSI ports, etc providing 
an architecture that is operating-vendor-independent and adapts to existing system, creating 
scalable drives from high-end workstations to high-end server, as taught by Specs. 

Regarding claim 15, lOP supports at least one or more input/output processors (See Specs: 120 
standard hardware architecture is defined for a single host entity and an intelligent I/O subsystem 
containing a number of I/O processors entities, host comprising application(s) and their resources, 
executing an operating system. Fig. 2-1, an lOP platform consists of a processor, memory and I/O 
devices, page 2-1), and comprises: 

a device driver module which interfaces the local storage devices for controlling said array 
of local storage devices (Heil, col 1 1 /lines 12-35, device driver module 260); and 

a communication layer which defines a mechanism for communications between the system 
driver module and the device driver module (see Specs: I2O communication layer (messaging 
service layer), which delivers I/O transactions messages from one software module to another, any 
where in the I2O domain, independent of the modules hierarchy, section 2.1.3, page 2-4, Fig. 2-3). 
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Regarding claim 2, lOP access module is one of a hardware module (Heil: col 11/lines 28-35), a 
combined hardware/software module (Heil: col 10/lines 43-50), and a software module provided on 
a tangible medium (Heil: col 10/lines 28-50). 



Regarding claims 3 and 8, discussed on claims claim 1 and 14, further wherein a communication 
between host computer nodes on a server cluster system and another system (Heil. host computer 
nodes on a server cluster, abstract, system interconnected via a data network, col 9/lines 11-17). 

Regarding claim 4, said lOP which comprises: at least one or more input/output processors (see 
Specs, page 2-1); at least one storage device as said input/output devices (Heil: disks 118, col 
11/lines 7-35); a device driver module arranged to control access via interface means with said 
storage device (Heil: software driver 260, col 11/lines 7-12, 28-35); a communication layer which 
defines a mechanism for communications between the ISM driver 250 (Local Transport) and the 
HDM (260); (Heil: software driver 250, col 1 1/lines 12-27, supporting communication between 250 
and 260, see Specs messaging (communication) layer section 2.1.3, page 2-4, Fig. 2-3). 

Regarding claims 5, 6, 9, 10, and 16, wherein said communication layer is responsible for 
managing and dispatching all service requests (see Specs: section 2.1,3, page 2-4, Fig. 2-3 
communication layer is a network of object instance) and providing a set of APIs for delivering 
messages along with a set of support routines that process the messages (see Specs: messaging is an 
interface between the modules, this interface is a set of APIs that provide transport and message 
services, page 2-5), and is comprised of a message layer which sets up a communication session 
(see Specs: section 2.1.6, page 2.18), and transport layer which defines how information will be 
shared (Heil coordinate retrieval of shared information, col 10/lines 66-col 1 1/line 1 1). 



Regarding claim 7, as discussed on claims 1/14, fiirther a communication layer which defines a 
mechanism for communications between the system driver layer and the device driver layer (see 
Specs: I2O communication layer (messaging service layer), which delivers I/O transactions 
messages fi"om one software module to another, any where in the I2O domain, independent of the 
modules hierarchy, section 2.1.3, page 2-4, Fig. 2-3). 
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Regarding claim 1 1 , wherein said system driver module and said device driver module constitute a 
single device (Heil, col 10/lines 43-47, stackable device drivers in a single module) that is portable 
across a plurality of host operating systems and host network platforms (See Specs: to enable 
device drivers to port across target processors, device driver source code is written in ANSI C, 
section 1.2, page 1-4), and works interoperable with a plurality of storage devices and host 
operating systems (See Specs, coexists with existing device drivers, such as device drivers of 
multiple classes, and device drives can scale across system platforms, from high-end workstations 
to high-end server, page 1-4, C code provides portability across platforms, section 2.5.2.1, page 1- 
40). 

Regarding claim 12, wherein said system host driver layer and said device driver layer operate in 
accordance with an I2O specification for allowing storage devices to operate independently from the 
operating system of the host server (Heil, 10, lines 28-42, computer nodes of a server, see abstract). 

Regarding claim 13, this claim is substantially the same to claim 2, as discussed, same rationale is 
applicable. 

Regarding claim 17-18, this claims is substantially the same as claims 11-12 as discussed, same 
rationale is applicable. 



5. Claims 19-28 are rejected under 35 U.S.C. 103(a) as being unpatentable over Heil et. al. 
(Heil) U.S. Patent No. 6,173,374 in view of Intelligent I/O (120) Architecture Specification 
(Specs), version 1.5, March 1997. 

Regarding claim 19, wherein, upon initialization, a software 250 driver (Local Transport) scans the 
local bus so as to locate and initialize all local input/output platforms (lOPs) and builds an opaque 
"context*' structure for each input/output platform (lOP); 

Specs: teach building a list of designations for each lOP, wherein after the lOP 
loads, it executes its initialization sequence, causing the lOP to scan its physical adapters, load and 
initialize appropriate devices, and build a logical configuration table, section 2.1.7.2, page 2.25, 
located lOP is added to the system configuration table, host then gives each lOP a list of all lOPs, 
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section 2.1.4.1, page 2-11, said table lists all the lOP's registered devices and their availability, 
item 8, page 4-65, for each device registered, the driver provides a list of message handlers, one for 
each message function, received messages handlers are used to builds a message dispatch table, 
section 2.2.4.3, page 2-32, each registered 120 device provides message handlers that process the 
messages to the device, the identify of the event handler is accompanied by a context variable so 
that the message variable can determine the associated I/O transaction of each registered lOP, 
section 2.2.4.1, section Page 2-32. 

wherein software driver 240 (Remote Transport) prepares to accept requests from a remote 
server through said computer network, (Heil: Software drivers 240 arranged to manage the 
reception of remotely generated requests from the network for local data to be exported onto the 
computer network, col 1 1/hnes 36-46, remote computer nodes of a server cluster, abstract), and 

means for building an lOP descriptor structure for each input/output platform (lOP) which 
includes an exported table of function call pointers and the context required by the software driver 
250 to communicate with the input/output platform (lOP); 

Specs: Each I2O device is created with a unique TID and associated with an event 
queue, lOP and driver communicate via API function calls. Driver supplies a pointer to the (lOP 
descriptor function table) message dispatch table when the device is created. This table lists 
Function codes, their priorities and message handlers for processing request messages. When 
communicating with the lOP, the lOP receives a request message to that TID, the lOP uses the 
message's Function code (fijnction call), queues the request to the event queue. If the driver sends 
requests, it must register their reply handlers (i.e. send/receive handlers) and priorities via an API 
fixnction call Handles are placed in a structure and which returns an InitiatorContext value 
identifying that structure. When a Driver sends a request, it uses the appropriate InitiatorContext 
value. When a reply is received, the IRTOS retrieves the reply handler and priority from a structure 
identified by the InitiatorContext field and then queues the event, section 5.1.5, page 5-4, section 
5.2-6, page 5-14; In this manner an lOP descriptor structure for each input/output platform (lOP) is 
built, which includes an exported table of function call pointers and the context required by the 
driver to communicate with the input/output platform (lOP); connection using said direct call path 
between the driver 250 and driver 240, discussed above in claims 1 and 14; 

and means for establishing a network management communication channel through the 
driver 240 (Heil, col 11/lines 54-65, shipping via 240, col 10/line 65-col 10/line 17), and means 



Application No. 09/215,788 (CO^HaN et al.) 
Art Unit No. 2152 

which waits for a connection (see Specs, table 4-5, page 4-16, connection_fail, timeout waiting for 
response), however neither Heil nor Specs teach determining the number of lOP; 

Bonola teaches means for determining upon initiahzation and a starting process, the 
number of CPU's present in the computer system along with the context of the computer system, 
col 9/lines 55-58, teaching means for querying so as to determine the number of input/output 
processing (lOP), col 8/line 5-13, 58-64); 

It would have been obvious to one ordinary skilled in the art at the time the invention was 
made to modify existing teachings with means for determining the number of lOP as taught by 
Bonola motivation would be to prevent error in the installation phase determining the actual of 
detected processor, utilizing said number and the context information to initialize the drivers, 
supporting the allocation of shared memory without requiring extra memory, as in the prior art. 

Regarding claim 20, wherein said software driver 250 further has a send handler fiinction and said 
driver 240 further has a receive handler function which are respective program interfaces for 
receiving an inbound message from a remote server on said computer network for direct access to 
local lOP and for delivering an outbound message to said remote server on said computer network. 

Specs teaches wherein for lOP- lOP communication, inbound/outbound message queue 
location are exchanges, section 2.1.4.1, and page 2-11; when communicating with the lOP, the lOP 
receives a request message to that TID, the lOP uses the message's Function code (function call), 
queues the request to the event queue. If the driver sends requests, it must register their reply 
handlers via an API function call. When a Driver sends a request, it uses the appropriate 
InitiatorContext value from handles are placed in a structure and which retums an InitiatorContext 
value identifying that structure. When a reply is received, the reply handler are retrieved from a 
structure identified by the InitiatorContext field and then queues the event, section 5.1.5, page 5-4, 
section 5,2.6, page 5-14; In this manner an lOP descriptor structure for each input/output platform 
(lOP) is built, which includes an exported table of function call pointers and the context required by 
the driver to communicate with the input/output platform (lOP); In this manner send/receive 
(request/reply) handlers are exchange for corresponding inbound and outbound messages between 
the local and remote lOP modules. 
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Regarding claim 21, wherein said Remote Transport further builds an lOP connection structure 
including at least an lOP descriptor pointer which refers to the lOP descriptor structure of the 
Connection Manager for making a direct call to the Local Transport through the receive handler 
function and the send handler function. 

Specs teaches a connection message structure is used by an lOP to connect one of its drivers 
and a device registered on another lOP, lOPs using send/receive request messages, messages 
comprising descriptor structure (e.g. InitiatorDevice and TargetDevice) used to refer to the driver 
and lOP that will send requests and the device on I0P2 that will receive them, section, page 4-20, 
said descriptor identifies the driver and the lOP, adapters and device types, section 5.2.1, page 5-7; 
lOP descriptor structure for each input/output platform (lOP) is built, which includes an exported 
table of function call (send/receive handler) pointers and the context required by the driver to 
communicate with the input/output platform (lOP); connection using said direct call path between 
the driver 250 and driver 240, discussed above in claims 1 and 14; wherein said connection request 
and its reply convey information enabling the two lOPs to establish a direct path for exchanging 
messages, section 2.1.4.1, and page 2-11. 

Regarding claim 22, as discussed on claims 1 and 14, further providing a direct call access to said 
storage devices for said remote server to share resources of said storage devices by exporting said 
resources, as discussed above, further while bypassing operating system protocol stacks; Heil: 
software driver 240 and 250 discussed above, provide exporting functions will bypassing operating 
system protocol stacks 260, col 10/line 66-col 35 enabling exporting supported by software driver 
250 comprising a cache maintaining updated data from the data from the local blocks 118, this 
supports the bypassing of protocol stack 260, for exporting local storage device onto a computer 
network, where I/O shipping 270 managing the reception of remotely generated requests from the 
other system network for local data to be exported onto the computer network, and I/O shipping 
HDM 280 manages the communication medium, as discuss above. 



Regarding claim 23, the claim comprise a combination of previously discussed claim limitation, 
these claims are 22, 1, 7, and 19. 
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Regarding claim 24, this claim comprises the same limitations as those in claim 4, wherein Local 
Transport is not denoted system driver module 



Regarding claim 25, this claim comprises the same limitation as those in claims 5 and 6, same 
rationale is applicable. 



Regarding claim 26, this claim comprised the same limitations as in claim 1 1 and 12,same rationale 
is applicable- 
Regarding claims 28-27, this claims are substantially the same as claims 19-20, respectively, same 
rationale is applicable. 
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